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respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
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Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
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Foreword 



This Technical Specification (TS) has been produced by ETSI Technical Committee Electronic Signatures and 
Infrastructures (ESI). 

The present document is part 6, sub-part 1 of a multi-part deliverable. Full details of the entire series can be found in 
part 1 [1]. 



Introduction 

The summarised scope of each part and sub-part can be found in part 1 [1] of this multi-part deliverable. 
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Scope 



The present document specifies requirements for achieving interoperability between the Registered Electronic Mail 
systems that are compliant with TS 102 640 (REM henceforth) specification [1] to [3] and systems that are compliant 
with UPU S52-1 UPU Postal Registered electronic Mail functional specification (PReM henceforth) [4]. 

The approach used for this purpose is to define all the necessary mappings between the two specifications taking into 
account also the objective to maintain and preserve the positive features present in both the realities as pursued in the 
Technical Specifications. 

The present document is structured as follows: 

• Clause 4: General requirements. 

• Clause 5: Mapping of terms and definitions among REM and PReM. 

• Clause 6: Mapping of boundary roles. 

• Clause 7: Functional GAP analysis between REM and PReM. 

• Clause 8: High level definition of the inter-communication flows between REM and PReM. 

• Clause 9: Mapping of exchanged formats (structure of messages, attachments, signature etc). 

• Clause 10: Mapping of evidence names and semantics. 

• Clause 1 1 : Mapping of protocol elements. 

• Clause 12: Definition of mutual recognition system based on ETSI-TSL and UPU-Designated Operator 
Trusted List. 



References 



References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the 
referenced document (including any amendments) applies. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee 
their long term validity. 

2.1 Normative references 

The following referenced documents are necessary for the application of the present document. 

[1] ETSI TS 102 640-1: "Electronic Signatures and Infrastructures (ESI); Registered Electronic Mail 

(REM); Part 1: Architecture". 

[2] ETSI TS 102 640-2: "Electronic Signatures and Infrastructures (ESI); Registered Electronic Mail 

(REM); Part 2: Data requirements, Formats and Signatures for REM". 

[3] ETSI TS 102 640-5: "Electronic Signatures and Infrastructures (ESI); Registered Electronic Mail 

(REM); Part 5: REM-MD Interoperability Profiles". 

[4] UPU S52-1: "Functional specification for postal registered electronic mail". 

NOTE: The present document has been produced on the version 1 of the aforementioned UPU specification. 
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[5] ETSI TS 102 231: "Electronic Signatures and Infrastructures (ESI); Provision of harmonized 

Trust-service status information" . 

2.2 Informative references 

The following referenced documents are not necessary for the application of the present document but they assist the 
user with regard to a particular subject area. 

[i.l] ETSI TS 102 640-3: "Electronic Signatures and Infrastructures (ESI); Registered Electronic Mail 

(REM); Part 3: Information Security Policy Requirements for REM Management Domains". 

[i.2] ETSI TS 102 640-4: "Electronic Signatures and Infrastructures (ESI); Registered Electronic Mail 

(REM); Part 4: REM-MD Conformance Profiles". 

[i.3] ETSI TS 102 640-6-2: "Electronic Signatures and Infrastructures (ESI); Registered Electronic 

Mail (REM); Part 6: Interoperability profiles; Sub-part 2: REM-MD BUSDOX Interoperability 
Profile". 

[i.4] ETSI TS 102 640-6-3: "Electronic Signatures and Infrastructures (ESI); Registered Electronic 

Mail (REM); Part 6: Interoperability profiles; Sub-part 3: REM-MD SOAP Binding Profile". 



[i.5] IETF RFC 5321 

[i.6] IETF RFC 5322 

[i.7] IETF RFC 5751 

Specification". 



"Simple Mail Transfer Protocol". 

"Internet Message Format". 

"Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message 



[i.8] ISO 3 166-1 : "Codes for the representation of names of countries and their subdivisions — Part 1 : 

Country codes". 

[i.9] ISO/IEC 27001:2005: "Information technology — Security techniques — Information security 

management systems — Requirements". 



Definitions and abbreviations 



3.1 Definitions 

For the purposes of the present document, the terms and definitions given in TS 102 640-1 [1] to TS 102 640-5 [3], 
TS 102 231 [5], UPU S52-1 [4] and the following apply: 

REM/PReM Gateway: set of technical and physical components, policies and processes that provide the Gateway 
service among REM network and UPU/PReM network 

NOTE: A REM/PReM Gateway may be a sub-service/module of a REM-MD or to be separated service. 

Throughout the present document a number of verbal forms are used, whose meaning is defined below: 

• shall, shall not: indicate requirements strictly to be followed in order to conform to the present document and 
from which no deviation is permitted. 

• should, should not: indicate that among several possibilities one is recommended as particularly suitable, 
without mentioning or excluding others, or that a certain course of action is preferred but not necessarily 
required, or that (in the negative form) a certain possibility or course of action is deprecated but not prohibited. 

• may, need not: indicate a course of action permissible within the limits of the present document. 
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3.2 



Abbreviations 



For the purposes of the present document, the following abbreviations apply: 
DO Designated Operator 

NOTE: Definition in UPU S52-1 [4]. 



General requirements 



This clause describes the tools and the formalities used for defining the profile in the present document. 



4.1 Compliance requirements 



Requirements are grouped in three different categories, each one having its corresponding identifier. Table 1 defines 
these categories and their identifiers. 

Table 1 : Requirements categories 



Identifier 


Requirement to implement 


M 


System shall implement the element. 


R 


System should implement the element. 





System may implement the element. 



All the requirements of Table 8, Table 9, Table 11, Table 12 and Table 15 will be defined as follows. 

Table 2: Requirements template 



N 2 


Service / Protocol 
element 


TS reference 


Requirement 


Implementation 
guidance 


Notes 







































Column N° will identify a unique number for the requirements. This number will start from 1 in each clause. The 
eventual references to it would also include the clause number to avoid any ambiguity. 

Column Service / Protocol element will identify the service element or protocol element the requirement applies to. 

Column TS Reference will reference the relevant clause of the standard where the element is defined. The reference is 
to TS 102 640-1 [1], TS 102 640-2 [2], TS 102 640-3 [i.l], TS 102 640-4 [i.2], TS 102 640-5 [3] or PReM UPU [4] 
specification except where explicitly indicated otherwise. 

Column Requirement will contain an identifier, as defined in Table 1 . 

Column Implementation guidance will contain letters referencing explanation of the requirement. 

Column Notes will contain additional notes as informative text to the requirement. 



Mapping of terms and definitions 



In Table 3 a mapping among the main terms and definitions used in REM Technical specifications [1], [2], [i.l], [i.2], 
[3] and equivalent terms used in PReM UPU [4] specification is provided. An empty cell means that the corresponding 
specification does not define an equivalent term of the one shown in the same row and defined in the other 
specification. 
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Table 3: Mapping of definitions 



ETSI REM definitions 


UPU PReM definitions 


certification authority 




information security policy 




Information Security Management System 




long term storage 




message archive 


Message Store + Evidence Store 


original message 


PReM Object 


REM-MD repository 


Directory Server+Evidence Store+Message Store 


Registered E-Mail 


Postal Registered eMail 


REM dispatch 


PReM Message 


REM Management Domain 


Designated Operator 


REM-MD envelope 


Signed part of PReM Message 


REM-MD evidence 


Evidence 


REM-MD Evidence Provider 


Designated Operator 


REM-MD Evidence Verifier 


Designated Operator 


REM-MD Message 


PReM Message 


REM-MD Message Gateway 


Designated Operator 


REM-MD Message Transfer Agent 




REM-MD Repository Retrieval Interface 




REM-MD Sender Message Submission Interface 




REM-MD Third Party Evidence Retrieval Interface 




REM Message Store 


Message Store 


REM Object 


PReM Object or PReM Message or PReM Dispatch 


REM Objects Relay Interface 




REM User Agent (REM-UA) 


Web-browser/email client software 


REM Policy 


PReM policy 


REM Policy Domain 


UPU PReM group 


REM Policy Domain Authority 


UPU 


REM Recipient 


Addressee / Mailee 


REM Sender 


Mailer 


REM Third Party 


Authorized party 


Signature Creation Server 




Time-Stamping Authority 




Time-Stamp Token 






Notification 




Designated Operator Trust List 



Mapping of boundary roles 



For the purposes of the present document only the boundary elements of both systems shall be considered. In particular, 
as outlined in Figure 1, the main roles involved in the interactions are: REM-MDs, Designated Operators, Trusted Lists. 
A new element is needed to cover the gap between the two systems: it is called REM/PReM Gateway. 

The REM/PReM Gateway shall act with double role: it shall be considered as a generic REM-MD when the 
intercommunication is between REM network <--> REM/PReM Gateway; in a similar way, the REM/PReM Gateway 
shall be considered as one of the Designated Operators of the UPU/PReM network when the intercommunication is 
between REM/PReM Gateway <--> PReM network. 



7 Functional GAP analysis between REM and PReM 

The main differences between the functional aspects of ETSI REM and UPU PReM will be identified in this clause by 
comparing, when possible, the similar aspects of the two systems under analysis. 

The format of the exchanged messages in the REM model to which the present document refers is based on the MIME 
standard (RFC 5751 [i.7]) enriched with a set of typical Headers of the SMTP (RFC 5321 [i.5]) messaging protocol. 

Clause 6.1 of TS 102 640-1 [1] and clause 5.1 of TS 102 640-2 [2] define the "Events" and the corresponding 
"Evidence" produced for each of these events. 
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Sections 5.2 and 7.2 of UPU PReM Technical Specification [4] define a functional description of the PReM service 
flow. 

Each event/evidence is associated to a function and a mapping between functions is identified in the following tables. 
The attention is concentrated to the boundary functions that are involved in the gateway among REM and PReM 
systems. Anyway, some other remarkable function is inserted in the table to provide a more general view when 
significant for the interoperability. 

The analysis is organized in a table with two columns where the first one always contains a list of the events and 
relevant evidence of the flows of a REM system. The second column always contains a similar list with corresponding 
functions of a PReM system. The order of the contents (cells of left/right) does not depend on the direction of the flow. 
There is a correspondence between the two systems comparing, line by line, the left cell with right cell. When possible 
the events/evidence/functions are grouped for analogy of meaning. Events or functions that are not present in one of the 
two systems are identified in the comments. Internal events/functions that are not relevant for interoperability are 
neglected in this analysis. 

Table 4: GAP Analysis - Transmission/Relay/Delivery - REM-MD -> DO 



Opr. 


ETSI REM Events (TS 102 640-1 [1], clause 6.2) 


UPU PReM functions, events, and 




and Evidence (TS 102 640-2 [2], clause 5.1) 


descriptions (UPU PReM Technical 
Specification [4], sections 5.2 and 8.3) 




Function: 


Function/Method: 




Relay 


SendMessageToDestination 




This is the general operation (performed from a 
REM-MD to a destination Designated Operator) to 
convey a REM-MD Message containing the Sender's 


This is the real function invoked from the 
REM/PReM Gateway that, when executed at 
DO side, allows PReM Message to be sent to 




message. 


DO of Destination. 




To cover the gap among the two systems, the 




O 

Q 

+■* 
c/> 

<L> 


operation requires a gateway. 




Function: 


Function/Method: 


Q 

Q 

■ 


Relay 


SubscribeNotification 


This is the general operation (performed from the 


This is the real function that allows the 


LU 


Recipient's Designated Operator to Sender's 


REM/PReM Gateway system to subscribe 


CC 


REM-MD) to convey a REM-MD Message containing 


certain PReM events, and to be notified through 


™ 


an evidence relevant to a Sender's message. 


a call to the ReceiveNotification function, when 


o 




these events occur. 


> 
Q 


To cover the gap among the two systems, the 




operation requires a gateway. 




Events: 


Events: 


(0 


6.2.2 Event B.1 - R-REM-MD Acceptance 


Events 5.1 , in the Workflow Process of Figure 3, 


0) 


6.2.2 Event B.2 - R-REM-MD Rejection 


interpreted as result of the 


CC 




SendMessageToDestination execution (relay 


c 
o 


This event occurs at Sender's REM-MD side in 


operation) for Receive/NotReceive the message 


■(/> 


consequence of the result of the relay operation. 


conveyed from a Sender's REM-MD to a 


(/) 

E 

C/> 

c 

(0 




Recipient's DO. 


Evidence: 


Evidence: 


I- 


5.1.2 Evidence RelayToREMMDAcceptanceRejection 


EFW-DSP-ACC/REJDOD Evidence of Forward - 
Acceptance/Rejection - DOD #4 Table 4 




The responsible for issuance of this recommended 


section 8.3 of PReM UPU [4] TS. 




evidence should be the Recipient's DO but it is not 






present in the workflow of section 5.2.3 of PReM 


This evidence seems equivalent to the required 




UPU [4] TS. The REM/PReM Gateway shall generate 


RelayToREMMDAcceptanceRejection but it is 




such evidence for the Sender, on behalf of the 


not issued by a DO and it is only logged. 




Recipient's DO, using as input the result of the 






SendMessageToDestination operation. 
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Opr. 


ETSI REM Events (TS 102 640-1 [1], clause 6.2) 
and Evidence (TS 102 640-2 [2], clause 5.1) 


UPU PReM functions, events, and 

descriptions (UPU PReM Technical 

Specification [4], sections 5.2 and 8.3) 




Event: 


Event: 




6.2.2 Event B.3 - Expiration of time to deliver to 
R-REM-MD 


This event makes sense at Sender's REM-MD 
side, so it is not considered here. 




This event occurs at Sender's REM-MD side when the 
attempts of relay within a fixed interval of time fail 
completely. 




Evidence: 


Evidence: 




5.1.3 Evidence RelayToREMMDFailure 

The responsible for issuance of this evidence is the 
Sender's REM-MD and the recipient of the evidence is 
the Sender. 


In the flow direction under analysis an evidence 
like that indicated in the left cell makes sense 
only at Sender's REM-MD side and so it is not 
considered here. 


Events: 


Events: 




6.2.3 Event C.1 - Message Delivery 


Event 5.8 of the Workflow Process of 
section 5.2.3 of PReM UPU [4] TS (summarized 
in Figure 3 of the present document) for 
Acceptance/Non-Acceptance of the message 
conveyed from the Sender's REM-MD to the 
Recipient's DO. 


Evidence: 


Evidence: 




5.1.4 Evidence DeliveryNonDeliveryToRecipient 


E-DSP-ACC/REJ-DOD Evidence of PReM 
Dispatch Acceptance/Rejection - DOD #27 
Table 4 section 8.3. of PReM UPU [4] TS. 

The responsible for issuance of this evidence is 
the Recipient's DO. The 

'DeliveryNonDeliveryToRecipient' evidence shall 
be notified to the Sender's REM-MD, via the call- 
back function subscribed at REM/PReM 
Gateway level, by means of the 
ReceiveNotification. The function 
ReceiveNotification is invoked by the Recipient's 
DO and executed at REM/PReM Gateway level. 


Event: 


Event: 




6.2.3 Event C.2 - Expiration of time to deliver message 

This event occurs at Sender's REM-MD side when no 
positive delivery evidence for a sent message is 
received in a fixed time. 


In this profile, this event makes sense only at 
Sender's REM-MD side, so it is not considered 
here. 


Evidence: 


Evidence: 




5.1.4 Evidence DeliveryNonDeliveryToRecipient 

The responsible for issuance of this evidence is the 
Sender's REM-MD and the recipient of the evidence is 
the Sender. 


In this profile an evidence like that indicated in 
the left cell makes sense only at Sender's 
REM-MD side and so it is not considered here. 
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Table 5: GAP Analysis - Transmission/Relay/Delivery - DO -> REM-MD 



Opr 


ETSI REM Events (TS 102 640-1 [1], 


UPU PReM functions, events and descriptions 




clause 6.2) and Evidence 


(UPU PReM Technical Specification [4], 




(TS 102 640-2 [2], clause 5.1) 


sections 5.2 and 8.3) 




Function: 


Function/Method: 




Relay 


SendMessageToDestination 




This is the general operation (performed from a 


This is the real function invoked from the Sender's DO 




Designated Operator to a destination 


that, when executed at REM/PReM Gateway side, 




REM-MD) to convey a REM-MD Message 


allows PReM Message to be sent to the REM-MD of 




containing the Sender's message. 


Destination. 




To cover the gap among the two systems, the 






operation requires a gateway. 




Function: 


Function/Method: 




Relay 


ReceiveNotif ication : 




This is the general operation (performed from a 


This is the real function subscribed from Sender's DO 




REM-MD to a Designated Operator) to convey 


that, when invoked from Recipient's REM/PReM 




a REM-MD Message containing an evidence 


Gateway, allows REM-MD system to notify certain 




relevant to a Sender's message. 


REM-MD events when these occur. The execution of 


s* 




the ReceiveNotification function happens at Sender's 


u 

2 


To cover the gap among the two systems, the 


Designated Operator side. 


■ 

LU 
DC 

*-* 


operation requires a gateway. 




Events: 


Events: 


<D 

Q 


6.2.2 Event B.1 - R-REM-MD Acceptance 


Events 5.1 in the Workflow Process of section 5.2.3 of 


* 


6.2.2 Event B.2 - R-REM-MD Rejection 


PReM UPU [4] TS (summarized in Figure 3 of the 


O 




present document) interpreted as consequence of the 


Q 


This event occurs at Recipient's REM-MD side 


execution of relay operation (at REM/PReM Gateway 


d) 


in consequence of the execution of the relay 


side) for Receive/NotReceive the message conveyed 


O 


operation. 


from the Sender's DO to the Recipient's REM-MD. The 


> 




event is the result of the SendMessageToDestination 


> 
Q 




operation executed at REM/PReM Gateway level. 


Evidence: 


Evidence: 


i 


5.1.2 Evidence 


EFW-DSP-ACC/REJDOD Evidence of Forward - 


0) 
DC 


RelayToREMMDAcceptanceRejection 


Acceptance/Rejection - DOD #4 Table 4 section 8.3 of 


"- 




PReM UPU [4] TS. 


o 


In REM network, the responsible for issuance of 






this recommended evidence is the Recipient's 


This evidence is substantial equivalent to the required 


I 


REM-MD and the primary intended recipient is 


RelayToREMMDAcceptanceRejection but, in the 


(0 


the Sender's REM-MD (in this particular flow it 


workflow of section 5.2.3 of PReM UPU [4] TS, it is 


(0 


is a Sender's DO). Since the workflow of 


only logged and not issued. This means that an 


I- 


section 5.2.3 of PReM UPU [4] TS does not 


evidence of this type, coming from a REM network 




have this evidence at Sender's DO side (this 


through the REM/PReM Gateway, would not be 




means that it is not expected nor recognized), it 


recognized by the Sender's DO. So, even if it is 




may be simply logged at REM/PReM Gateway 


generated in the REM network, it shall be only logged 




side, and not sent back to the Sender's DO. 


in the REM/PReM Gateway. 


Event: 


Event 




6.2.2 Event B.3 - Expiration of time to deliver to 


This event makes sense when the Sender's operator is 




R-REM-MD 


a REM-MD. 




This event makes sense when the Sender's 






operator is a REM-MD. 




Evidence: 


Evidence: 




5.1.3 Evidence RelayToREMMDFailure 


This evidence makes sense when the Sender's 
operator is a REM-MD. 




This event makes sense when the Sender's 






operator is a REM-MD. 
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Opr 


ETSI REM Events (TS 102 640-1 [1], 


UPU PReM functions, events and descriptions 




clause 6.2) and Evidence 


(UPU PReM Technical Specification [4], 




(TS 102 640-2 [2], clause 5.1) 


sections 5.2 and 8.3) 




Events: 


Events: 




6.2.3 Event C.1 - Message Delivery 


Event 6.1 of the Workflow Process of section 5.2.3 of 
PReM UPU [4] TS (summarized in Figure 3 of the 
present document) for Acceptance/Non-Acceptance of 
the message conveyed from the Sender's DO to the 
Recipient's REM-MD. 


Evidence: 


Evidence: 




5.1.4 Evidence DeliveryNonDeliveryToRecipient 


E-DSP-ACC/REJ-DOD Evidence of PReM Dispatch 
Acceptance/Rejection - DOD #27 Table 4 section 8.3 




The responsible for issuance of this evidence is 


of PReM UPU [4] TS. 




the Recipient's REM-MD. The 






'DeliveryNonDeliveryToRecipient' evidence 


The evidence 'DeliveryNonDeliveryToRecipient' shall 




shall be notified to the Sender's DO, via the 


be received by the Sender's DO executing the 




call-back function subscribed at Sender's DO 


ReceiveNotification function invoked by the 




level, by means of the ReceiveNotification. The 


REM/PReM Gateway, as indicated in the left cell. 




function ReceiveNotification is invoked by the 






REM/PReM Gateway (when the event C.1 






occurs at Recipient's REM-MD) and executed 






at Sender's DO level. 




Event: 


Event 




6.2.3 Event C.2 - Expiration of time to deliver 


In this profile, this event makes sense only at Sender's 




message 


REM-MD side. 




This event makes sense when the Sender's 






operator is a REM-MD. 




Evidence: 


Evidence: 




5.1.4 Evidence DeliveryNonDeliveryToRecipient 


In this profile, this evidence makes sense only at 
Sender's REM-MD side. 




This evidence makes sense when the Sender's 






operator is a REM-MD. 





Table 6: GAP Analysis - Retrieval - REM-MD -> DO 



Opr 


ETSI REM Events (TS 102 640-1 [1], 

clause 6.2) 

and Evidence (TS 102 640-2 [2], clause 5.1) 


UPU PReM functions, events and descriptions 

(UPU PReM Technical Specification [4], 

sections 5.2 and 8.3) 


O 
Q 

*-* 
c/> 

<D 

Q 

Q 

■ 

LU 
CC 

.5? 
O 

> 
™ 

CC 


Function: 

Retrieval 

The retrieval operation (performed at 
Designated Operator level) generates some 
evidence relevant to a Sender's message. 

To cover the gap among the two systems, the 
operation requires a gateway. 


Function/Method: 

SubscribeNotification 

This is the real function that allows the REM/PReM 
Gateway system to subscribe certain PReM events, 
and to be notified through a call to the 
ReceiveNotification function, when these events occur. 


Function: 

Retrieval 

The retrieval operation (performed from a 
Designated Operator level) generates some 
evidence relevant to a Sender's message. 

To cover the gap among the two systems, the 
operation requires a gateway. 


Function/Method: 

RejectMessage 

The Recipient may explicitly Rejects the message with 
RejectMessage function. 

This is the real function that allows PReM system to 
notify REM Senders, through a gateway, the 
Recipient's rejection of the message. 
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Opr 



ETSI REM Events (TS 102 640-1 [1], 

clause 6.2) 

and Evidence (TS 102 640-2 [2], clause 5.1) 



UPU PReM functions, events and descriptions 

(UPU PReM Technical Specification [4], 
sections 5.2 and 8.3) 



Events: 



6.2.3 Event F.1 (mailbox) - Retrieval 



Evidence: 

5.1.6 Evidence 
RetrievalNonRetrievalByRecipient 



Events: 

6.2.3 Event F.2 (mailbox) 
Retrieval 



Events: 

Event 9.3 in the Workflow Process of section 5.2.3 of 
PReM UPU [4] TS for Retrieval of the message 
conveyed from the Sender's REM-MD to the 
Recipient's DO. 

The Recipient explicitly Rejects the message with the 
invocation of the RejectMessage function. The 
RejectMessage function is translated in the proper 
evidence (Mailee #31 Table 4 section 8.3 of PReM 
UPU [4] TS) notified by the Recipient's DO invoking the 
ReceiveNotification function. 

This event is mapped with the 
'AcceptanceRejectionByRecipient' REM-MD Evidence. 

The Recipient Accepts the message and Retrieves it 
with RetrieveResult function: these two functions are 
available in REM system and they are related to the 
event F.1. 



Evidence: 

E-MSG-ADRDLV/NDL-DOD Evidence of Delivery/Non- 
delivery - Addressee/Mailee #29 Table 4 section 8.3 of 
PReM UPU [4] TS. 

E-MSG-ADR-REJDOD Evidence of Reject - 
Addressee/Mailee #31 Table 4 section 8.3 of PReM 
UPU [4] TS. 

The responsible for issuance of "Retrieval" optional 
evidence is the Recipient's DO. The evidence shall be 
notified to the Sender's REM-MD, via the call-back 
function subscribed at REM/PReM Gateway level, by 
means of the ReceiveNotification function invoked by 
the Recipient's DO (Event 10.4 in the Workflow 
Process of section 5.2.3 of PReM UPU [4] TS). 

The responsible for issuance of "Reject" optional 
evidence is the Recipient's DO. It shall be notified to 
the Sender's REM-MD, via the call-back function 
subscribed at REM/PReM Gateway level, by means of 
the ReceiveNotification function invoked by the 
Recipient's DO (Event 10.4 in the Workflow Process of 
section 5.2.3 of PReM UPU [4] TS). 



Expiration of time for 



Events: 

Event 9.3 in the Workflow Process of section 5.2.3 of 
PReM UPU [4] TS for Retrieval of the message 
conveyed from the Sender's REM-MD to the 
Recipient's DO. 

The Recipient Ignores the message and it expires: 
This behaviour is available in REM system and it is 
related to the event F.2. 
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Opr 


ETSI REM Events (TS 102 640-1 [1], 

clause 6.2) 

and Evidence (TS 102 640-2 [2], clause 5.1) 


UPU PReM functions, events and descriptions 

(UPU PReM Technical Specification [4], 

sections 5.2 and 8.3) 




Evidence: 

5.1.6 Evidence 
RetrievalNonRetrievalByRecipient 


Evidence: 

30 E-MSG-ADR-EXPDOD Evidence of PReM 
Message Expiration - Addressee/Mailee. 

The responsible for issuance of "Expiration" optional 
evidence is the Recipient's DO. It shall be notified to 
the Sender's REM-MD, via the call-back function 
subscribed at REM/PReM Gateway level, by means of 
the ReceiveNotification function invoked by the 
Recipient's DO. 



Table 7: GAP Analysis - Retrieval - DO -^REM-MD 



Opr 


ETSI REM Events (TS 102 640-1 [1], 


UPU PReM functions, events and descriptions 




clause 6.2) and Evidence 


(UPU PReM Technical Specification [4], 




(TS 102 640-2 [2], clause 5.1) 


sections 5.2 and 8.3) 




Function: 


Function/Method: 




Retrieval 


ReceiveNotification : 




The retrieval operation (performed at REM-MD 


This is the real function subscribed from Sender's DO 




level) generates some evidence relevant to a 


that, when invoked from Recipient's REM/PReM 




Sender's message. 


Gateway, allows REM-MD system to notify certain 
REM-MD events when these occur. The execution of 




To cover the gap among the two systems, the 


the ReceiveNotification function happens at Sender's 


Q 


operation requires a gateway. 


Designated Operator side. 


Events: 


Events: 


■ 

LU 


6.2.3 Event F.1 (mailbox) - Retrieval 


Event 11.1 in the Workflow Process of section 5.2.3 




of PReM UPU [4] TS (summarized in Figure 3 of the 


C£ 


This event occurs at Recipient's REM-MD side 


present document) to receive the notification of the 


4-* 

c/> 


in consequence of the execution of the 


message retrieved at Recipient's REM-MD side. 


Q 
O 


retrieval operation. 




Evidence: 


Evidence: 




5.1.6 Evidence 


E-MSG-ADRDLV/NDL-DOD Evidence of 


™ 

o 


RetrievalNonRetrievalByRecipient 


Delivery/Non-delivery - Addressee/Mailee #29 






Table 4 section 8.3 of PReM UPU [4] TS. 


75 

> 


In REM network, the responsible for issuance of 




™ 


this optional evidence is the Recipient's REM- 


E-MSG-ADR-REJDOD Evidence of Reject - 


(D 


MD and the primary intended recipient is the 


Addressee/Mailee #31 Table 4 section 8.3 of PReM 


CC 


Sender (in this particular flow it is a PReM 
sender). The RetrievalNonRetrievalByRecipient 


UPU [4] TS. 




evidence, when issued, shall be notified to the 


The responsible for issuance of "Retrieval" optional 




Sender's DO (that after will notify this evidence 


evidence is the Recipient's REM-MD. The 




to the intended PReM sender), via the call-back 


RetrievalNonRetrievalByRecipient shall be mapped, 




function subscribed at Sender's DO level, by 


at REM/PReM Gateway level, to one of the above 




means of the ReceiveNotification. The function 


PReM evidence types according to REM Evidence 




ReceiveNotification is invoked by the 


Event Code. 




REM/PReM Gateway (when the event F.1 






occurs at Recipient's REM-MD side) and 






executed at Sender's DO level. 
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Opr 


ETSI REM Events (TS 102 640-1 [1], 

clause 6.2) and Evidence 

(TS 102 640-2 [2], clause 5.1) 


UPU PReM functions, events and descriptions 

(UPU PReM Technical Specification [4], 

sections 5.2 and 8.3) 




Events: 

6.2.3 Event F.2 (mailbox) - Expiration of time for 
Retrieval 


Events: 

Event 9.3 in the Workflow Process of section 5.2.3 of 
PReM UPU [4] TS for Retrieval of the message 
conveyed from the Sender's REM-MD to the 
Recipient's DO. 

The Recipient ignores the message and it expires: 
This behaviour is available in REM system and it is 
related to the event F.2. 


Evidence: 

5.1.6 Evidence 
RetrievalNonRetrievalByRecipient 

In REM network, the responsible for issuance of 
this optional evidence is the Recipient's REM- 
MD and the primary intended recipient is the 
Sender (in this particular flow it is a PReM 
sender). The RetrievalNonRetrievalByRecipient 
evidence, when issued, shall be notified to the 
Sender's DO (that after will notify this evidence 
to the intended PReM sender), via the call-back 
function subscribed at Sender's DO level, by 
means of the ReceiveNotification. The function 
ReceiveNotification is invoked by the 
REM/PReM Gateway (when the event F.2 
occurs at Recipient's REM-MD side) and 
executed at Sender's DO level. 


Evidence: 

30 E-MSG-ADR-EXPDOD Evidence of PReM 
Message Expiration - Addressee/Mailee. 

The responsible for issuance of "Expiration" optional 
evidence is the Recipient's REM-MD. It shall be 
notified to the Sender's DO, via the call-back function 
subscribed by Sender's DO, by means of the 
ReceiveNotification function invoked by the 
REM/PReM Gateway. 

The responsible for issuance of "Expiration" optional 
evidence is the Recipient's REM-MD. The 
RetrievalNonRetrievalByRecipient shall be mapped, 
at REM/PReM Gateway level, to PReM evidence 
indicated above. 



8 



High level definition of the inter-communication flows 
between REM and PReM 



8.1 Agreements 



The interchange among a PReM system and a REM system is governed by an agreement among at least one REM 
Management Domain and one UPU Designated Operator. This agreement is part of a more high-level agreement among 
a UPU PReM Policy Domain and a REM Policy Domain (the REM terms are used in this context but the designated 
authorities are present behind these terms). The first Policy Domain, PReM-PD, represents the environment (common 
set of rules) of the universe PReM. The second Policy Domain, REM-PD, defines the space within which it has life the 
particular instance of REM to put in communication with the PReM. From the technical point of view, the agreement 
among the UPU PReM Policy Domain and a REM Policy Domain requires the application of the present technical 
specification that provides the support for the interoperability. Whereas, regarding the operational level, the agreement 
among REM-MDs and DOs is concretised with a registration inside a special trusted index. These indexes shall be 
secured and trusted with an implementation like that defined in clause 12. 
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Figure 1 

In Figure 1 a description of the main points of contact and interaction is represented. 

The normal flows among REM-MDs are represented with the label "1". In a similar way the normal flow among PReM 
Designated Operators is indicated with the label "3". 

The interaction from REM to PReM, identified by the labels "2" and "4", happens through a REM/PReM Gateway 
implemented according to the profile defined in the present technical specification. From the point of view of any single 
REM-MD, the interaction through the Gateway ("2") is identical to that towards another generic REM-MD of the same 
system ("1"). The information, instead of arriving to a local REM-MD, flows towards a remote Designated Operator of 
the PReM system ("2" + "4") through the Gateway. The REM/PReM Gateway may be implemented to have a 
behaviour like a normal REM-MD or it may collapse in a particular role of an existing REM-MD. In Figure 1 an 
explicit separation is outlined for clarity reasons. 

Conversely, the interaction from PReM to REM happens through a REM/PReM Gateway and it is identified by the 
labels "4" + "2". Other than the role in REM network defined above, in the UPU/PReM network the REM/PReM 
Gateway shall also be considered as one of the Designated Operators or to be collapsed in a particular role of an 
existing DO. 

The addressing bridging between these two systems is effected through a mutual acknowledgment by means of specific 
indexes implemented for this purpose. The validation and trusting of these indexes shall be implemented through the 
REM-TSL and PReM Designated Operators Trust List, identified by the label "5". Indexes implementation details are 
out of the scope of the present document. 
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8.2 Operational scenario 



A typical operational scenario when a message flows from a REM system to a PReM system and vice versa is defined 
in this clause. 

The directions of the collateral informative flows on which the two main flows are based are: 

• When a REM User is the initiator of a message for a PReM User: 

REM^PReM (REM send a dispatch to PReM), 
REM<-PReM (REM receive the list of evidence from PReM). 

• When a PReM User is the initiator of a message for a REM User: 

PReM^REM (PReM send a dispatch to REM), 

PReM <- REM (PReM receive the list of evidence from REM). 

The profile to use between the REM Sender and the REM/PReM Gateway (through the REM-MD and the REM-UA) 
shall be the "REM-MD Interoperability Profiles" defined in TS 102 640-5 [3] REM technical specification. To simplify 
the description the terms REM Sender and REM Recipient shall be used in the present document without an explicit 
mention of the REM-UA role that is always present in the middle to such type of interactions. Similarly REM "Senders" 
and "Recipients" are generic terms that shall mean any entity like Process Applications, human users without any other 
explicit mention. 



Mapping of exchanged formats 



The main aspects to consider during the interchanges between two messaging systems are those relevant to the structure 
of the messages: 

• attachments 

• signatures 

• evidence 

An explicit normative reference to the REM ETSI TS [2] is reported in sections 2, 8.2, 8.4 and 8.5 of PReM UPU [4] 
specification regarding the formats of the messages (and the formats of the types of evidence). So in a normal case, 
when a PReM system interacts in a homogeneous way with another PReM system, it already uses the REM 
specification for the formats of the PReM Messages and the formats of the evidence. 

Under this light, in the case of interaction among REM and PReM systems, the format of the messages/evidence 
exchanged is exactly the same defined in REM ETSI TS [2] specification and other additional requirement shall not be 
needed. Figure 2 defines some detail of the format. Section 3.9 of UPU PReM Technical Specification [4] also defines 
the formatting of attachments using a MIME structure and the signature of the external envelope using S/MIME 
specification (as also defined in the normative reference to REM ETSI TS [2] specification). 

Whereas the formats of the evidence are outwardly the same format of the messages, the list of types of evidence is 
considered apart in clause 10. 
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1 Mapping of evidence names and semantics 

For the UPU/PReM network, the types of evidence and their usage are defined in sections 8.2 and 5.2 of the PReM 
UPU [4] technical specification. In REM network all the evidence types are defined in TS 102 640-2 [2] clause 5.1. 

According with the aforementioned definitions and with the GAP Analysis of clause 7, the list of the types of evidence 
may be classified in: 

• Evidence internal to REM-MD (or internal to the Designated Operator using the PReM UPU [4] terminology): 
these are the cases when both Sender and Recipients belong to the same REM-MD (or the same Designated 
Operator). Even in this case, the evidence is produced, available for the users and logged locally to the 
Designated Operator. 

• Evidence between the REM-MD and the Sender/Recipient (or between a Designated Operator and a 
mailee/addressee using the PReM UPU [4] terminology): this is the direct evidence that flows from a 
REM-MD (or Designated Operator) and the users registered to it. 

• Evidence among REM-MD s (or among the Designated Operators according to the PReM UPU [4] 
terminology): this is the evidence that flows between different REM-MD (or different Designated Operators). 

Only the third list of types of evidence is interesting for the purposes of interoperability, object of the present document. 
In fact, when two different systems REM/PReM need to interoperate, only the third type of evidence shall flow 
between the two types of systems and so between REM-MD and DO (and vice versa according to the flow direction). 



1 1 Mapping of protocol elements 

In section 5.2.5 of the PReM UPU [4] specification it is recommended that the interchange of messages (Dispatches) 
among two Designated Operators (REM-MD in REM terminology) is operated through Web Services. 

The packages of information conveyed among Designated Operators are fully defined in the PReM UPU [4] 
specification as a XML schema and an associated WSDL. 

A specific "Data" element is defined in the XML schema. It is a b64 binary element that shall host the REM Dispatch 
to be transmitted from a Designated Operator to another one. The same process shall be applied also in case of a 
REM-MD Message constituted by an evidence. The REM/PReM Gateway shall include the REM Dispatch or the 
REM-MD Message within a PReM WebService structure as specified in sections 7.1.7.2, 8.1 and 8.3 of the PReM UPU 
[4] specification. 

11.1 Enveloping REM Dispatch in PReM Web Service business 
payload 

Figure 2 illustrates how is implemented this mapping/embodying of REM Dispatch or REM-MD Messages to PReM 
Dispatch structure as WebService business payload. 
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REM level at sender side. 

User level and REM level at 
recipient side 



Figure 2 



The envelope on the right part of Figure 2 represents the entire REM Dispatch according to the TS 102 640-1 [1], 
TS 102 640-2 [2] and TS 102 640-5 [3] (equivalent to the PReM Message, in UPU Terminology). 

The Sender's pay load is the internal enveloped content indicated as "Original Message" in Figure 2. 

The Recipient shall receive the entire content (indicated as "REM Dispatch" in Figure 2) containing the "untouched" 
Sender's payload. Some variant to this schema may be possible according to the following rules: 

• The REM Dispatch/REM-MD Message may contain other attachments (for own purposes of UPU/PReM 
service), but the basic structure with the mandatory elements defined in the TS 102 640-1 [1], 

TS 102 640-2 [2] and TS 102 640-5 [3] shall be maintained unchanged. 

• The REM-MD Message representing an evidence (generally without a Sender's payload) shall be enveloped in 
the PReM WebService Structure exactly as for the REM Dispatch (that contains the Original Message/Sender's 
payload). 

The mapping described in Figure 2 is implicitly performed when a UPU Designated Operator needs to intemperate with 
another UPU Designated Operator according to the specification PReM UPU [4] . 

In consequence, a REM/PReM Gateway: 

1) shall build up an appropriate PReM Web Service structure around the normal REM Dispatch, when the 
direction is REM -> PReM. This PReM Web Service structure shall be submitted to the UPU/PReM network 
in order to be delivered to the intended PReM recipient; 

2) shall extract the REM-MD Message, containing some evidence, from the "Data" element, when the direction 
of the Sender's message is REM -> PReM (and so the direction of the evidence messages is PReM -> REM). 
These evidence messages shall be submitted to the REM network in order to be delivered to the intended REM 
recipient; 
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3) shall extract the REM Dispatch contained in the "Data" element, when the direction is PReM -> REM. This 
REM-MD Message containing the Sender's payload shall be submitted to the REM network in order to be 
delivered to the intended REM Recipient; 

4) shall build up an appropriate PReM Web Service structure around the normal REM-MD Message that 
contains an evidence, when the direction of the Sender's message is PReM -> REM (and so the direction of the 
evidence messages is REM -> PReM). These PReM Web Service structure shall be submitted to the 
UPU/PReM network in order to be delivered to the intended PReM recipient. 

Next clauses specify the processing to be implemented by the gateway. 

1 1 .2 PReM Designated Operators - relay Web Service Interface 

The main purpose of the present document is directed to specify the requirements for a REM/PReM Gateway guarantor 
of the interoperability among REM-MD and PReM Designated Operators. The attention of this clause is concentrated to 
analyse the Web Service operations (verbs in UPU PReM terminology) defined in PReM UPU [4] specification for the 
interaction among homogenous PReM Designated Operators. The analysis of these verbs allows to define the interface 
needed in the interoperability among REM-MD and PReM Designated Operators. 

The workflow among two general PReM Designated Operators is represented in Figure 3. This workflow is coherent 
with the workflow defined in section 5.2.3 of PReM UPU [4] specification. It is purged of sub-flows not relevant for 
interoperability purposes (that are represented by a cloud) and only the boundary functionalities are mentioned. 
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PReM inner functionanities 
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Figure 3: Synthesis of section 5.2.3 of PReM UPU [4] TS 
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The list of PReM verbs relevant for interoperability, that are mainly used in the functions represented in Figure 3, are: 

• SendMessageToDestination; 

• SubscribeNotification; 

• UnsubscribeNotification; 

• ReceiveNotification; 

• RejectMessage. 

As defined in clause 6 the REM/PReM Gateway shall act with double role: "a generic REM-MD" plus "a Designated 
Operators" according to the direction of the interaction. Under this light the typical usage of the previous functions is 
the following: 

• Case of REM-MD that needs to relay a REM-MD Message to a PReM DO: REM/PReM: 

The REM/PReM Gateway shall register itself to receive notifications/evidence using the method 
"SubscribeNotification" (this operation is done rarely, typically during the setup of the system). 

A REM-MD shall relay a REM Dispatch or REM-MD Message and this, through the REM/PReM 
Gateway, shall be sent to the correct PReM DO of destination by means of the 
SendMessageToDestination method. 

The PReM DO of destination, shall deliver the incoming PReM Message to the Recipient 
(Addressee/Mailee in PReM terminology) using the SendMessageToDestination method. 

The REM/PReM Gateway shall receive the evidence coming from the remote PReM DO of destination 
using the ReceiveNotification method. The evidence shall be extracted and sent back to the originator 
REM-MD. 

• Case of PReM DO that needs to relay a PReM Message to a REM-MD: PReM^REM: 

The PReM DO of origin shall register itself to receive notifications/evidence using the method 
"SubscribeNotification" (this operation is done rarely, typically during the setup of the system). 

The PReM DO of origin shall send a PReM Message to the REM/PReM Gateway by means of 
SendMessageToDestination method and this, through the REM/PReM Gateway shall be sent to the 
correct Recipient's REM-MD. 

The Recipient's REM-MD, shall deliver the REM-MD Message obtained by the incoming PReM 
Message (the REM/PReM Gateway shall extract the REM-MD Message as payload of the PReM 
Message) to the Recipient. 

The REM/PReM Gateway shall receive the evidence messages coming from the Recipient's REM-MD 
and shall notify them to the PReM DO of origin that, using the ReceiveNotification method shall 
receive all the evidence messages. 

A full description of the mapping for these functions is given in the next clauses. 

1 1 .2.1 SendMessageToDestination 

The SendMessageToDestination method is used to send a PReM Message from a Designated Operator to another 
Designated Operator. In the context of the present document, the role of one of the Designated Operators (Recipient's 
DO or Sender's DO according to the direction of the flow) shall be covered by the REM/PReM Gateway. 

The XML schema of such operation may be found in sections 7.1.7.1 and 7.1.7.2 of PReM UPU [4] specification. 

1 1 .2.1 .1 Mapping of fields during a REM -> PReM flow 

The following table profiles the SendMessageToDestination operation in the use case of a REM-MD sending REM 
Dispatch to a PReM DO. 
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Table 8: SendMessageToDestination XML elements 



N 2 


Service / Protocol element 


PReM UPU [4] 
reference 


Requirement 


Implementation 
guidance 


Notes 


1 


EndLifeCycle 


Clause 7.1.7.1 


M 


a 




2 


ExtendLifeCycle 


Clause 7.1.7.1 


M 


b 




3 


IssuePostMarkedReceipt 


Clause 7.1.7.1 


M 


c 




4 


TransactionKey 


Clause 7.1.7.1 


M 


d 




5 


OriginalClaimedldentity 


Clause 7.1.7.1 


M 


e 




6 


Claimedldentity 


Clause 7.1.7.1 


M 


f 




7 


OrganizationID 


Clause 7.1.7.1 


R 


g 




8 


ClientApplication 


Clause 7.1.7.1 


M 


h 




9 


Contentldentifier 


Clause 7.1.7.1 


O 


i 




10 


Destination 


Clause 7.1.7.1 


M 


I 




11 


Timeout 


Clause 7.1.7.1 


M 


m 




12 


Data 


Clause 7.1.7.1 


M 


n 




13 


ContentMetadata 


Clause 7.1.7.1 


O 








Implementation guidance: 

a) The SendMessageToDestination shall contain 'EndLifeCycle' element indicating if the current operation is at 
the "end" of the business transaction lifecycle. Since in REM the concept of business transaction lifecycle is 
not present, its value shall be set to true, where the meaning is that any interaction is always at the start/end of 
the transaction lifecycle. 

b) The SendMessageToDestination shall contain 'ExtendLifeCycle' element indicating if the current operation 
extends the business transaction lifecycle. Its value shall be set to false. 

c) The SendMessageToDestination shall contain 'IssuePostMarkedReceipt' element indicating if a specific 
"PostMark" receipt (to attest that the REM Dispatch has been successfully received by the remote PReM 
Designated Operator) is required. Its value should be false unless the Sender's REM-MD is able to interpret 
such receipt. 

d) The SendMessageToDestination shall contain 'TransactionKey' element that is a complex type including a 
unique transaction identifier. In order to have a unique identifier important for correlation of the exchanged 
REM Dispatch and relevant evidence the value of its significant components shall be set as follows: 

i) CountryCode: <two-bytes of the sender country according to the ISO 3166-1 [i.8] country code list> 

ii) Version: <"1.0"> 

iii) Key: <the Message-ID value of the REM-MD Message envelope> 

e) The SendMessageToDestination shall contain 'OriginalClaimedldentity' element that is a complex type 
specifying the original unique identification of the Sender. The value of its significant components shall be set 
as follows: 

i) NameQualifier: <the Internet Domain address of the Sender's e-mail address (the part on the right of the 
'@' in the e-mail address according to the standard RFC 5322 [i.6])> 

ii) Format: http://tools.ietf.Org/html/rfc5322#section-3.4.l 

iii) UserlD: <the user part of Internet e-mail address of the Sender's e-mail address (the part on the left of the 
'@' in the e-mail address according to the standard RFC 5322 [i.6])> 

f) The SendMessageToDestination shall contain 'Claimedldentity' element that is a complex type specifying the 
actual identification of the Sender. The value of its significant components shall be set to the same value of the 
OriginalClaimedldentity components (implementation guidance e). 

g) The SendMessageToDestination should contain 'OrganizationID' element specifying the identifier of the 
organization that provides the REM/PReM Gateway service. If present, its value should be set to the same 
value of the TSP name present in Table 17 of Trusted Service Providers List for this organization. 
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h) The SendMessageToDestination shall contain 'ClientApplication' element that is a complex type specifying 
the client application requesting the SendMessageToDestination. The value of its significant component shall 
be set as follows: 

i) NameAndVersion: "REM/PReM Gateway vl.O" 

i) The SendMessageToDestination may contain 'Contentldentifier' element specifying an identifier of the 
content. If present, its value shall be set to "REM-MD Message". 

j) The SendMessageToDestination shall contain 'Destination' element specifying the e-mail destination 
addresses. Its value shall be set to a list of e-mail addresses (according to the syntax specified in 
RFC 5322 [i.6]) relevant to a single remote PReM Designated Operator. If the REM Dispatch is directed to 
many e-mail addresses belonging to different remote PReM Designated Operators, the same REM Dispatch 
shall be sent many times, one per each remote Designated Operator. In each of these 
SendMessageToDestination invocations the element "destination" shall be set to the exact list of addresses 
relevant for each remote PReM Designated Operator. It is out of scope of the present document to specify the 
routing aspects (e.g. how the messages are routed from any REM-MD to the remote DO through the 
REM/PReM Gateway). 

k) The SendMessageToDestination shall contain 'Timeout' element specifying the period of time (in hours) that 
the Recipient's DO should wait before considering a PReM Message as "not received" by the Recipient (if set 
to means that the timeout value is determined by the Recipient's DO). Its value should be set to the same 
time period defined in laws/statutory requirements or local policies of REM network. In case no time period is 
specified at REM level the value may be used in Timeout element, indicating to use the Recipient's DO 
default value (that in any case may override any specified value, as indicated in section 7.2.7.2 of PReM 
UPU [4] specification). 

1) The SendMessageToDestination shall contain 'Data' element that is a complex type specifying a binary 

element (in b64 form) which embodies the entire REM Dispatch (or the REM-MD Message) to convey using 
the SendMessageToDestination method. The value of its significant component shall be set as follows: 

i) MimeType: "message/rfc822" 

ii) base64Binary: <the base64 encoding of the entire REM-MD Message in MIME format> 

m) The SendMessageToDestination may contain 'ContentMetadata' element that is a complex type specifying a 
sequence of custom details regarding the REM-MD Message. If present its value shall be set as follows: 

i) MetadataName: <name of the metadata> 

ii) MetadataValue: < value of the metadata> 

The REM/PReM Gateway may elaborate the answer of the SendMessageToDestination operation in order to produce 
some new local Evidence to return back to the REM Sender, whenever this is not explicitly expected from the PReM 
system. 

1 1 .2.1 .2 Mapping of fields during a PReM -> REM flow 

The REM/PReM Gateway shall parse any PReM Dispatch coming from the PReM network and shall extract REM 
Dispatch from the XML "Data" element. The REM Dispatch coming from the PReM network shall be auto consistent 
in the sense that, according to the aspects considered in clause 9 of the present document, it shall have all the REM 
fields correctly and coherently compiled to be interpreted by the destination REM system. 

The REM/PReM Gateway shall decode any REM Dispatch (extracted as indicated above) from the base64 format and 
shall submit it to the REM network. The submission operation requires to compile the "forward-path" and "reverse- 
path" for the correct addressing to the proper REM-MDs and to avoid loops and/or multiple submissions of the same 
message. The two terms "forward" and "reverse" path are used in the present document like their usage in 
RFC 5321 [i.5]. 
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Below follows a non-normative example of how the "forward-path" and "reverse-path" are compiled: 

This operation may be performed as follows: 

i) collect all the "To:" and "Cc:" MIME Headers from the REM Dispatch extracted from the 'Data' element; 

ii) select all the destination addresses that are belonging to the REM system. This may be done by a lookup 
to some specific trusted index (see clause 12 for trust building); 

iii) insert all the addresses selected in the previous point as "forward-path" for the correct routing of the REM-MD 

Message; 

iv) collect the "Reply-To:" MIME Headers from the REM Dispatch extracted from the 'Data' element and 
set it as "reverse-path" for the correct return path to use in case of exceptions. 

It is out of scope of the present document to specify further these routing aspects. 

1 1 .2.2 SubscribeNotification 

In the context of the present document, the SubscribeNotification method shall be used to cover the following 
situations: 

• Used by the REM/PReM Gateway for subscribing itself to the event notification service of the PReM system. 
In this situation the SubscribeNotification is that usually implemented by any remote PReM DO. 

• Used by any remote PReM Designated Operators to subscribe themselves to be notified on the relevant events 
(called evidence in REM terminology) occurring at REM/PReM Gateway side. In this situation the 
SubscribeNotification shall be implemented by the REM/PReM Gateway. 

There is a direct correspondence among the PReM notifications and the REM-MD Evidence types. It is required an 
invocation of this function for each event type (and so evidence type) that needs to be notified to the REM/PReM 
Gateway. 

The REM/PReM Gateway shall subscribe itself, using the SubscribeNotification function, to each Designated Operator 
of the PReM system that needs to use the gatewaying function with REM. Conversely, all these Designated Operators 
of the PReM system that need to use the gatewaying function with REM shall subscribe themselves, using the 
SubscribeNotification function to the REM/PReM Gateway. 

This invocation is a "registration" of information (containing also a call-back URL), so it is performed rarely, and 
typically at configuration time. Other means to register the required information may be possible under particular 
agreements among the REM/PReM Gateway providers and PReM DO providers. Specification of alternative means is 
out of scope of the present document. 

The XML schema of such operation may be found in sections 7.1.9.1 and 7.1.9.2 of PReM UPU [4] specification. 

1 1 .2.2.1 Mapping of fields during a REM -> PReM flow 

Any DO shall implement the function SubscribeNotification. The REM/PReM Gateway shall subscribe itself to be 
notified on events (evidence in REM terminology) occurring in any remote DO. Any event occurring at DO side means 
a specific invocations to the ReceiveNotification (defined in clause 11.2.4.1) URL subscribed by the REM/PReM 
Gateway with SubscribeNotification method. 

Table 9 contains the mapping of the elements of SubscribeNotification, function invoked from the REM/PReM 
Gateway and implemented in any remote DO. 

Table 9: SubscribeNotifications elements - REM -> PReM 



N 2 


Service / Protocol element 


PReM UPU [4] 
reference 


Requirement 


Implementation 
guidance 


Notes 


1 


EventType 


Clause 7.1.9.1 


M 


a 




2 


ClientApplication 


Clause 7.1.9.1 


M 


b 




3 


CallbackUrl 


Clause 7.1.9.1 


M 


c 
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Implementation guidance: 

a) The SubscribeNotification shall contain 'EventType' element specifying the event to subscribe for which a 
notification is required. This function shall be invoked, from the REM/PReM Gateway, for each of the 
following events: 

i) "MessageDelivered" 

ii) "MessageUndelivered" 

iii) "MessageReadByAddresee" 

b) The SubscribeNotification shall contain 'ClientApplication' element that is a complex type specifying the 
client application requesting the SubscribeNotification. The value of its significant component shall be set as 
follows: 

i) NameAndVersion: "REM/PReM Gateway vl.O" 

c) The SubscribeNotification shall contain 'CallbackUrl' element specifying the call-back URL function that it is 
required to be invoked by any subscribed DO whenever the event denoted by EventType occurs. This URL 
shall implement a function according to the interface defined for the "ReceiveNotification" method, as 
described in clause 11.2.4.1 of the present document. The value of this element shall be set as follows: 

i) CallbackUrl: <URL of the WebService of the REM/PReM Gateway pointing to the ReceiveNotification 
function> 

Whenever some events occur at DO level, it shall invoke the specific ReceiveNotification call-back function 
as defined in clause 11.2.4.1 of the present document. 

1 1 .2.2.2 Mapping of fields during a PReM -> REM flow 

The REM/PReM Gateway shall implement the function SubscribeNotification. The remote PReM Designated 
Operators shall subscribe themselves to be notified on events (evidence in REM terminology) occurring in the 
REM/PReM Gateway. The REM-MD Messages containing evidence information directed to PReM Designated 
Operators shall be converted, by the REM/PReM Gateway, in specific invocations to the ReceiveNotification (defined 
in clause 11.2.4.2) URLs subscribed by any DO with SubscribeNotification method. 

Table 10 contains the mapping of the elements of SubscribeNotification, function implemented in the REM/PReM 
Gateway. 

Table 10: SubscribeNotifications elements - PReM -> REM 



N 2 


Service / Protocol element 


PReM UPU [4] 
reference 


Requirement 


Implementation 
guidance 


Notes 


1 


EventType 


Clause 7.1.9.1 


M 


a 




2 


ClientApplication 


Clause 7.1.9.1 


M 


b 




3 


CallbackUrl 


Clause 7.1.9.1 


M 


c 





Implementation guidance: 

a) 



The SubscribeNotification shall contain 'EventType' element specifying the event to subscribe for which a 
notification is required. This function shall be invoked, by any remote DO, for each of the following events: 

i) "MessageDelivered" 

ii) "MessageUndelivered" 

iii) "MessageReadByAddresee" 
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b) The SubscribeNotification shall contain 'ClientApplication' element that is a complex type specifying the 
client application requesting the SubscribeNotification. The value of its significant component may be set as 
follows: 

i) Name And Version: "Remote DO vl.O" 

Other values may be used by the DOs for this element. It is out of scope of the present document to 
provide further specification on this element since it is considered informative and not critical for the 
interoperability. 

c) The SubscribeNotification shall contain 'CallbackUrl' element specifying the call-back URL function that it is 
required to be invoked by the REM/PReM Gateway whenever the event denoted by EventType occurs. This 
URL shall implement a function according to the interface defined for the "ReceiveNotification" method, as 
described in clause 11.2.4.2 of the present document. The value of this element shall be set as follows: 

i) CallbackUrl: <URL of the WebService of the remote DO associated to the ReceiveNotification 
function> 

The REM/PReM Gateway shall maintain a configuration table with the following mapping. 
Table 11 : SubscribeNotifications - Event mapping - PReM -> REM 



PReM EventType 


REM Event (TS 102 640-1 [1], clause 6.2) 


MessageDelivered 


6.2.3 Event C.1 - Message Delivery 


MessageUndelivered 


6.2.3 Event C.2 - Expiration of time to deliver message 


MessageReadByAddresee 


6.2.3 Event F.1 (mailbox) - Retrieval 



Whenever a REM-MD Evidence, related to the specified REM Event, arrives to the REM/PReM Gateway, it 
shall invoke the specific ReceiveNotification call-back function for all the subscribed PReM Designated 
Operators as defined in clause 11.2.4.2 of the present document. 

1 1 .2.3 UnsubscribeNotification 

The UnsubscribeNotification method is useful to cancel a previous registration process performed by a 
SubscribeNotification. It is out of scope of the present document to list all the possible reasons requiring to unsubscribe 
a previous agreement. The full usage description of this method may be found in section 7.2.10 of PReM UPU [4] 
specification 

The REM/PReM Gateway requiring unsubscribing an agreement with some remote DO shall queue all the REM-MD 
Evidence messages directed to such remote DO. The REM-MD Evidence messages queued, when any subscription 
agreement with a remote DO is defined, shall subsequently be delivered as soon as a new subscription agreement will 
be effected. Further details on the subscription agreements are out of scope of the present document. 

1 1 .2.4 ReceiveNotification 

The ReceiveNotification method is used to receive evidence information whenever some event, subscribed with the 
method SubscribeNotification, occurs. 

The XML schema of such operation may be found in section 7.1.11.1 of PReM UPU [4] specification. 

1 1 .2.4.1 Mapping of fields during a REM -> PReM flow 

In this context the flow REM -> PReM means that a REM-MD Message (or a REM Dispatch) has been sent to a remote 
PReM Designated Operator and the relevant evidence needs to be received from the REM/PReM Gateway by means of 
ReceiveNotification. The REM/PReM Gateway shall implement the ReceiveNotification function and it shall be 
available at the URL subscribed as indicated in clause 11.2.2.1 of the present document. The following table contains 
the mapping of the relevant elements. 
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Table 12: ReceiveNotifications elements - REM -> PReM 



N 2 


Service / Protocol element 


PReM UPU [4] 
reference 


Requirement 


Implementation 
guidance 


Notes 


1 


TransactionKey 


Clause 7.1.1 1.1 


M 


a 




2 


EventType 


Clause 7.1.1 1.1 


M 


b 




3 


EventDateTime 


Clause 7.1.1 1.1 


M 


c 




4 


EventData 


Clause 7.1.1 1.1 


M 


d 





Implementation guidance: 



a) 



b) 



The ReceiveNotification shall contain TransactionKey' element specifying the TransactionKey returned back 
in the previous SubscribeNotification invocation. Even if the syntax of this element states that it is mandatory, 
its value shall be ignored, at REM/PReM Gateway side, during the implementation of ReceiveNotification. 

The ReceiveNotification shall contain 'EventType' element specifying the event that has occurred on the 
remote PReM Designated Operator, the invoker of ReceiveNotification. The REM/PReM Gateway shall 
extract the evidence from the ReceiveNotification and shall submit it in the REM network as described in 
implementation guidance d) below. The evidence shall be fully formatted and enveloped in the EventData 
element by the remote PReM Designated Operator according to the following mapping table: 

Table 13: ReceiveNotifications - Event mapping - REM -> PReM 



PReM EventType 


REM-MD Evidence (TS 102 640-1 [1], clause 5.1) 


MessageDelivered 


5.1 .4 DeliveryNonDeliveryToRecipient 


MessageUndelivered 


5.1 .4 DeliveryNonDeliveryToRecipient 


MessageReadByAddresee 


5.1 .6 RetrievalNonRetrievalByRecipient 



c) The ReceiveNotification shall contain 'EventDateTime' element specifying the date/time reference of the event 
which has just occurred. Even if the syntax of this element states that it is mandatory, its value shall be 
ignored, at REM/PReM Gateway side, during the implementation of ReceiveNotification. 

d) The ReceiveNotification shall contain 'EventData' element that is a complex type specifying a binary element 
(in b64 form) which embodies the entire REM-MD Message containing the REM-MD evidence to convey 
using the ReceiveNotification method. The value of its significant component shall be set as follows: 

i) MimeType: "message/rfc822" 

ii) base64Binary: <the base64 encoding of the entire REM-MD Message containing the evidence> 

The REM/PReM Gateway, executing the invocation of ReceiveNotification, shall decode the REM-MD Message 
containing the evidence, extracted from the element indicated above, from the base64 format and shall submit it in the 
REM network. The submission operation requires to compile the "forward-path" and "reverse-path" for the correct 
addressing to the proper REM-MDs and to avoid loops and/or multiple submissions of the same object. The two terms 
"forward" and "reverse" path are used in the present document like their usage in RFC 5321 [i.5]. 



Below follows a non-normative example of how the "forward-path" and "reverse-path" are compiled: 

This operation may be performed as follows: 

i) collect all the "To:" MIME Headers from the REM-MD Message extracted from the 'EventData' element 
and set the "forward-path" with this value; 

ii) collect the "From:" MIME Headers from the REM-MD Message extracted from the 'EventData' element 
and set it as "reverse-path" (for the correct return path in case of exceptions). 



It is out of scope of the present document to specify further these routing aspects. 
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1 1 .2.4.2 Mapping of fields during a PReM -> REM flow 

In this context the flow PReM -> REM means that a PReM Message has been sent from a PReM Designated Operator 
of origin to a REM-MD through the REM/PReM Gateway. The Gateway, receiving back the REM-MD Evidence from 
the Recipient's REM-MD, shall notify this to the PReM Designated Operator of origin by means the invocation of 
ReceiveNotification. The ReceiveNotification function will be available at the URL subscribed in advance by the PReM 
Designated Operator as indicated in clause 11.2.2.2 of the present document. 

The REM/PReM Gateway shall invoke the proper URL notifying the correct PReM EventType according to the 
following table: 

Table 14: ReceiveNotifications - Event mapping - PReM -> REM 



REM-MD Evidence (TS 102 640-1 [1], clause 5.1) 


PReM EventType 


5.1 .4 DeliveryNonDeliveryToRecipient - delivery case 


MessageDelivered 


5.1 .4 DeliveryNonDeliveryToRecipient - expiration time to delivery case 


MessageUndelivered 


5.1.6 RetrievalNonRetrievalByRecipient - retrieval case 


MessageReadByAddresee 



Table 15 contains the mapping of all the relevant elements of the ReceiveNotification invocation. 

Table 15: ReceiveNotifications elements - PReM -> REM 



N 2 


Service / Protocol element 


PReM UPU [4] 
reference 


Requirement 


Implementation 
guidance 


Notes 


1 


TransactionKey 


Clause 7.1.1 1.1 


M 


a 




2 


EventType 


Clause 7.1.1 1.1 


M 


b 




3 


EventDateTime 


Clause 7.1.1 1.1 


M 


c 




4 


EventData 


Clause 7.1.1 1.1 


M 


d 





Implementation guidance: 

a) The ReceiveNotification shall contain TransactionKey' element specifying the TransactionKey returned back 
in the previous SubscribeNotification invocation. 

b) The ReceiveNotification shall contain 'EventType' element specifying the event to transmit to the Sender's 
PReM Designated Operator (the initiator of the messaging transaction) according with Table 14. The 
REM/PReM Gateway shall invoke the ReceiveNotification submitting the REM-MD Message containing an 
evidence to the Sender's DO as described in implementation guidance d) below. 

c) The ReceiveNotification shall contain 'EventDateTime' element specifying the date/time reference of the event 
which has just occurred. This time should be collected from the evidence. 

d) The ReceiveNotification shall contain 'EventData' element that is a complex type specifying a binary element 
(in b64 form) which embodies the entire REM-MD Message containing the REM-MD evidence to be send 
back to the Sender's DO. The value of its significant component shall be set as follows: 

i) MimeType: "message/rfc822" 

ii) base64Binary: <the base64 encoding of the entire REM-MD Message containing the evidence> 

The REM/PReM Gateway, executing the invocation of ReceiveNotification, shall encode the REM-MD 
Message containing the evidence in base64 format and shall submit it to the Sender's DO. 

1 1 .2.5 RejectMessage 

The RejectMessage method is useful to explicitly indicate the will of the Recipient to reject the message. It is out of 
scope of the present document to list all the possible reasons requiring this method. The full usage description of this 
method may be found in section 7.2.8 of PReM UPU [4] specification. 

Since the event associated with rejection is present in both technical specifications REM and UPU/PReM, it may be 
used in both directions. 
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1 1 .2.5.1 Mapping of evidence during a REM -> PReM flow 

In this context the flow REM -> PReM means that a REM-MD Message (or a REM Dispatch) has been sent to a remote 
PReM Designated Operator and the final Recipient rejects the incoming message with an explicit declaration. This act 
is translated in an invocation to the RejectMessage method. 

The REM/PReM Gateway shall implement the RejectMessage mapping this event to the 

'AcceptanceRejectionByRecipient' REM-MD Evidence (with EventCode='Rejection'). The new REM-MD Evidence 
message composed by the REM/PReM Gateway shall be sent back to the REM Sender of the original message. It is out 
of scope of the present document how the REM/PReM Gateway maintains the correlation among all the sent/received 
information needed to compose the 'AcceptanceRejectionByRecipient' REM-MD Evidence. 

1 1 .2.5.2 Mapping of evidence during a PReM -> REM flow 

In this context the flow PReM -> REM means that a PReM Message has been sent to a REM Recipient and, in case of 
the optional reject mechanism is provided to the final user, this user rejects the incoming message with an explicit 
declaration. This declaration is translated, at Recipient's REM-MD level, in a generation of a 
AcceptanceRejectionByRecipient' REM-MD Evidence (with EventCode='Rejection'). 

The REM/PReM Gateway shall invoke the RejectMessage implemented and executed, as usual in PReM environment, 
by the Sender's DO. It is out of scope of the present document how the REM/PReM Gateway maintains the correlation 
among all the sent/received information needed to invoke the RejectMessage method. 



12 Definition of mutual recognition system based on 
ETSI-TSL and UPU-Designated Operator Trusted 
List 

This clause contains the specifications that should be implemented for cross-trusting between ETSI/REM and 
UPU/PReM networks. 

A PReM Policy Domain, according to PReM UPU [4] specification, is a collection of PReM enabled Designated 
Operators operating which belong to a group that is managed according to rules and regulations agreed by the group. 
Each PReM Designated Operator grants trust to the PReM End Users abiding by the same Policy Domain rules and 
granting that each PReM Message properly submitted is managed, tracked and delivered under the common Policy 
Domain rules. Digital signatures applied by PReM Designated Operators to PReM Messages and PReM Evidence 
certify the respect of the Policy Domain rules. UPU is responsible for Policy Domain rules establishment and supervises 
Designated Operators operating under Policy Domain rules. 

A PReM Trust List is required to support PReM End User or interested party to: 

• verify that the signing certificate used for PReM Dispatch is valid and belongs to an authorized Designated 
Operator 

• verify if the PReM Designated Operator belongs to the expected PReM Policy Domain 

• verify if the PReM Designated Operator current status was in accord with PReM Policy Domain rules when a 
signature envelope was created 

TSL defined in TS 102 231 [5] addresses those requirements and is the recommended instrument for a seamless mutual 
recognition between a REM and PReM systems evidence. When a TSL is used to implement or complement a PReM 
Trust List, TS 102 640-1 [1] shall apply. 

In term of domain trust the following mapping among PReM, REM and TSL defined roles is applied: 



• 



entity responsible for Policy Domain rules (i.e. UPU) - REM Policy Domain (REM-PD) - TSL Schema 
Operator 

PReM Designated Operator - REM Management Domain (REM-MD) - TSLTrust Service Provider (TSP) 

PReM Designated Operator signing service - REM-MD Evidence Provider - TSL Service 
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A TSL contains trust information, in a hierarchical format. Figure 4 shows the information contained in a TSL and how 
it is mapped to REM/PReM entities. 
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NOTE: The notations "[1]" and "[2]" in Figure 4 indicate the indexes of elements of the list. 

Figure 4: Mapping UPU Trust List to TSL (based on TS 102 231 [5]) 

When UPU, as responsible for PReM Policy Domain, issues a TSL, it acts as TSL schema operator and creates, signs 
and publishes the TSL. 

A TSL for PReM shall be of type Generic and all the Designated Operators shall be listed as TSP. Each of these should 
contain information related to REM-MD Evidence provider, current and historical information among which digital 
identity that can be used to verify the service signatures and status. 

It is assumed that each party that needs to verify a REM-MD Evidence should trust at least a Schema Operator. 

As non normative example, a REM User typically trusts TSLs issued by own REM-PD. 

A TSL issued for PReM should contain all the Designated Operators and the related certificated associated to the 
digital keys that they use to: 

i) digital sign the PReM Messages 

ii) verify integrity and trust of the PReM Messages (including the PReM Objects and Evidence) 

If a PReM Designated Operator certificate is no longer used (e.g. when approaching its expiration date) a new 
certificate is generated and associated to the service while the previous certificate is added to the service history. For 
each active signing digital key a Trusted Service element and its history shall be updated. No new Trusted Service entry 
should be added when a new signing key is generated and associated to a new certificate to renew an expiring one. 
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12.1 Scheme information section 



The scheme information section of a TSL issued by a PReM Policy Domain should be populated in conformance to 
Table 16. 

Table 16: UPU PReM TSL Scheme Information 



TSL field name 


Value 


TSL type (M) 


Set to 
M httD://uri.etsi.ora/TrstSvc/TSLTvDe/aeneric" 


Scheme operator name (M) 


See TS 102 231 [5] 


Scheme operator address (M) 


Scheme operator postal address (M) 


Scheme operator electronic address (M) 


Scheme name (M) 


Scheme information URI (M) 


Status determination approach (M) 


Set to "Active" 


Scheme type/community/rules (0) 


Set to "supervision" 


Scheme territory (O) 


Not present 


TSL policy/legal notice (M) 


See TS 102 231 [5] 


Historical information period (M) 


Pointers to other TSLs (0) 


Additional information field (0) 
Attribute of: Pointers to other TSLs 


List issue date and time (M) 


Next update (M) 


Distribution points (0) 


Scheme extensions (0) 


Not present 


List of Trust Service Providers (0) 
-> sequence of elements in Table 17 


List of Trust Service Providers as specified 
in clause 12.2 



1 2.2 List of Trust Service Providers section 

The List of Trust Service Providers section should be compiled according to Table 17. 

Table 17: List of Trust Service Providers 



TSL field 


Value 


TSP name (M) 


Set with the Designated Operator 
Name 


TSP trade name (M) 


See TS 102 231 [5] 


TSP address (M) 


TSP postal address (M) 


TSP electronic address (M) 


TSP information URI (M) 


An URI where general information 
relevant to the users like public 
certificates, addresses, etc. is 
published by the Designated Operator 


TSP information extensions (0) 


Not present 


List of services (M) 


Sequence of Trusted Service 
information elements as specified in 
clause 12.3 
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12.3 Trusted Service information section 

The List of Trust Service information section should be compiled according to Table 18. 

Table 18: Trusted Service information 



TSL field 


Value 


Service type identifier (M) 


The value shall be one of the 

following. 

Case of UPU/PReM TSP: 

http://www.upu.int/PReMService 


Case of ETSI/REM TSP: 

h tto ://u r i . ets i . o ra/TrstS vc/S vctvoe/R E M 


Service name (M) 


See TS 102 231 [5] 


Service digital identity (M) 


The Designated Operator Certificate 
X.509 certificate and optionally an 
X509 SKI element 


Service current status (M) 


Set to one of "In accord / Suspended / 
Revoked" 


Current status starting date and time (M) 


See TS 102 231 [5] 


Scheme service definition URI (0) 


Service supply points (0) 


TSP service definition URI (0) 


Optionally an URI for publishing 
general information relevant to the 
users like public certificates, 
addresses, etc. 


Service information extensions (0) 


Not present 


Service approval history (0) 


Sequence of service approval history 
elements as specified in clause 12.4 



12.4 Trusted Service approval history section 

The List of Trust Service approval history section should be compiled according to Table 19. 

Table 19: Service approval History 



TSL field 


Value 


Service type identifier 


See Table 18 


Service name 


See Table 18 


Service digital identity 


See Table 18 


Service previous status 


See TS 102 231 [5] 


Previous status starting date and time 


Service information extensions 


Not present 
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